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DESCRIPTION 



Bypassing Transcoding Operations in a Communication Network 



Field of the Invention 



The present invention relates to the call set-up in a communication networl<. More 
specifically, the invention relates to the bypassing of a pair of transcoding operations 
that are performed in series by a first transcoder arranged on a local side of the 
communication network and by a second transcoder located on a distant side 
thereof. 

Background of tlie Invention 

In digital systems for mobile communication speech signals are encoded by a speech 
encoder in order to reduce the data rate and for saving bandwidth. In a call originat- 
ing in a mobile terminal' and terminating in a mobile terminal, a so-called mobile-to- 
mobile call, the speech signal usually is encoded and decoded twice. In the originat- 
ing mobile terminal the speech signal is encoded a first time before the encoded 
signal is sent over the air to a first network node, e.g. a base station. A first 
transcoder decodes the encoded signal, which it receives from the first network 
node, into a so-called a-Iaw/|i-Iaw signal which is commonly used In fixed communi- 
cation networks. The decoded signal is routed in the fixed network to a second 
network node, e.g. a second base station. Before the second network node can 
transmit the signal, the signal is encoded again in a second transcoder. The encoded 
signal is emitted by the second network node and is decoded In the terminating 
mobile terminal. The speech signal flow in the opposite direction is handled symmet- 
rically. 

As in this configuration two encoder/decoder pairs are lined up (the encoder of the 
originating mobile terminal and the decoder of Ihe originating transcoder are re- 
garded as a first pair and the encoder of the terminating transcoder and the decoder 
of the terminating mobile terminal are regarded as a second pair), this configuration 
is called a speech codec "tandem". The key inconvenience of a tandem configuration 
is the speech quality degradation introduced by the double transcoding. This degra- 
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dation is usually more noticeable when the speech codecs are operating at low 
transmission rates. 

When the originating and the temiinating mobile terminal are using the same type of 
speech codec, it is possible to transmit the speech frames received from the originat- 
ing mobile terminal to the terminating mobile terminal without the need to activate 
the transcoding functions in the first and the second transcoder. As then there Is only 
one pair of encoder and decoder (that is, the encoder in the originating mobile . 
terminal and the decoder in the terminating mobile terminal) involved, this configura- 
tion is called Tandem Free Operation (TFO). In modern networi<s, like UTMS, it is 
even possible to discard the whole transcoder hardware. This is then called a 
Transcoder Free Operation (TrFO) instead of e.g. the usual a-law/^i-iaw signal. In 
TFO and TrFO mode the encoded and compressed speech signal is transmitiied over 
the fixed network. Besides the improvement of the speech quality by avoiding double 
transcoding TFO also saves costs as the compressed signal needs less bandwidth in 
the fixed network and power is saved since transcoding Is bypassed twice. All neces- 
sary methods for negotiating, establishing and maintaining a Tandem Free Operating 
connection (TFO connection) are standardized for codec types without configuration 
parameters (e.g. in GSM 08.62 for GSM_FR, GSM_HR and GSM_EFR) or for more 
complex codec types (e.g. the adaptive multi-code rate (AMR)) by the 3''' Generation 
Partnership Project (3GPP). 

In Technical Specification 3G TS 28.062 V.5.0.0; 3"* Generation Partnership project; 
Technical Specification Group Services & Systems Aspects; In-band Tandem Free 
Operation (TFO) of Speech Codecs; Stage 3; Service Description; Release 5, which Is 
exemplary in respect of bypassing serial transcoding operations, various aspects of 
TFO for 3GPP are illustrated. TFO is activated and controlled in 3GPP by so-called 
Transcoder Units after the completion of the call set-up phase at both ends of a 
mobile-to-mobile call configuration. The TFO protocol is fully handled and terminated 
in the Transcoder Units. For this reason, the Transcoder Units cannot be bypassed in 
TFO. This is the key difference In comparison with TrFO which is defined In 3GPP TS 
23.153. In return, the Transcoder Units continuously monitor the normal TFO and 
can terminate TFO as soon as necessar/ with limited impact on the speech quality. 

Before TFO is activated, the Transcoder Units exchange conventional 64 kbit/s PCM 
speech samples encoded according to a-law.or p-law. The Transcoder Units can also 
exchange TFO messages by stealing the least significant bit In ever/ 16th speech 
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sample (see annex A of 3GPP TS 28.062 V5.0.0 for the specification of the TFO 
message transmission rules and clauses 6 to 8 for the description of the TFO proce- 
dures and message contents). 

If compatible speech codec types and configurations are used at both ends of the 
mobile-to-mobile call configuration, the Transcoder Units automatically activate TFO. 
If incompatible speech codec types and/or configurations are used at both ends, then 
a codec mismatch situation exists. TFO cannot be activated until the codec mismatch 
is resolved. This capability is an optional feature involving other network elements of 
the Radio Access Network (RAN). 

Once TFO Is activated, the Transcoder Units exchange TFO frames canying com- 
pressed speech and in-band signaling, the structure of which is derived from the 
GSM TRAU frames defined in the 3GPP TS 48.060 and 48.061 (see clause 5). The 
exchange of TFO messages is still possible while TFO is active. In this case, the 
stealing process will result in embedding a message in the synchronization pattern of 
the TFO Frame. 

If the Transcoder Units find that the codec types currently used by both mobile 
terminals are compatible they will immediately enter into a TFO mode. Although the 
mobile terminals often support a codec type with better properties (e.g. better 
speech quality or better data rate) than the currently used codec type, very often 
they will not start with the optimal codec type because only the codec type currentiy 
In use Is signaled. If on the other hand both radio subsystems would always report 
the best codec type supported by the respective mobile terminal no agreement will 
be found and the communication will be started in tandem mode, although a TFO 
mode would have been possible. 

Although certain procedures ensure that in the course of the communication the 
communication connection can be switched to a common codec type and thus TFO 
can be enabled later on, the establishment is significantly delayed and the signal 
distortions in an Initial tandem operation mode are Inconvenient Therefore, one 
could think about reporting a codec type with lower properties but tiiat Is widely 
spread in order to establish TFO very early. As further on messages are exchanged 
that report a list of supported codec types of each terminal, in the course of the 
connection the codec type in use may be changed' to a better codec type. However 
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the users of the mobile terminals will experience the change of the codec while the 
TFO is established as (clicking) noise and may be irritated. 

It is an object of the invention to improve the bypassing of two or more transcoding 
operations that are performed in series. It is a furtlier object of the invention to allow 
an efficient protocol version handling. 

Summary of the Invention 

According to a first aspect, the Invention proposes a method of Initiating the bypass- 
ing of a pair of transcoding operations performed In series by a first transcoder 
arranged together with a first communication terminal on a local side of a communi- 
cation network and by a second transcoder arranged together with a second com- 
munication temiinal on a distant side of the communication networi<. The method 
comprises receiving from the distant side Information about an encoding format 
cun-ently in use on the distant side and about encoding capabilities of the distant 
side, and transmitting to the distant side information about an encoding format 
currently in use on the local side and about encoding capabilities of the local side to 
enable on one or on both sides a change of the encoding format currently in use 
prior to initiating the bypassing of the transcoding operations. 

Thus a change of the encoding format may be peri'ormed on the basis of an evalua- 
tion of local and distant encoding Infomiation, like the encoding format cun-ently In 
use and the encoding capabilities, before the transcoding operations are bypassed. 
This allows enter an operational mode bypassing the transcoding operations using an 
encoding format that is beneficial from the point of view of system operators and 
users. The encoding infomiation may be included in an Initial message requesting 
bypassing of the transcoding operations. 

A decision about the change of the encoding format may be performed even If 
compatible encoding formats are currently used on both sides. Thus, In the case of 
compatible encoding formats the transcoding operations may not be automatically 
bypassed but it may be dedded If the cun-ent encoding formats, although being 
compatible, actually constitute the best configuration available. 

The Information on the encoding capabilities of the distant side may be used to 
determine an alternative encoding format that is support:ed on both the local and the 
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dlstant side. The change of the encoding format may then effected on the basis of 
the aitemative encoding fomnat, e.g. by switching to this alternative encoding format. 

The infonnation about the encoding capabilities of the locai side or distant side may 
include the version of a bypassing protocol, such as a TFO protocol version, sup- 
ported by the local or distant transcoder. This allows for example to detect possible 
protocol conflicts at a very early stage and to decide if and how the conflicts can be 
resolved prior to bypassing the transcoding operations. In addition or as an alterna- 
tive to a version of a bypassing protocol, the information about the encoding capabili- 
ties of the local or distant side may include a list of encoding formats supported by 
the local or distant communication terminal or transcoder. For example the list of 
encoding formats nriay specify preferred encoding formats or aitemative encoding 
formats to the encoding forniat currently in use on a particular side of the communi- 
cation networlc 

As has been mentioned above, the local and distant encoding information, including 
the encoding format currently in use and the encoding capabilities, may form the 
basis for a decision regarding a possible change of the encoding format currently in 
use. A change of the encoding format may be effected with the purpose of establish- 
ing an optimal encoding configuration on the basis of compatible encoding formats 
on both sides. If for example one side or both sides currently use narrowband 
encoding formats but both sides support wideband encoding formats. It may be 
decided on one side or on both sides to switch to the usually more preferable wide- 
band encoding format prior to entering an operational state that bypasses the 
transcoding operations. 

If one side changes its encoding format it may notify the opposite side thereof. Such 
a notification may be performed prior to entering an operational mode that bypasses 
the transcoding operations. 

The bypassing protocol that is used for initiating the bypassing of the transcoding 
operations may Include different states. For example the bypassing protocol may 
include a contact state which may be entered as soon as It is clear that compatible 
encoding formats exist and which may precede the bypassing of the transcoding 
operations. The bypassing protocol may. further Include an operational state in which 
the transcoding operations are bypassed. 
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Based on the local and distant encoding information available on one of the two sides 
it may be decided to change the encoding format on one or and both sides. This 
decision may be performed prior to switching into the contact state or in the contact 
state. The actual change of the encoding formats may be perfomned in the contact 
state. A switch from the contact state Into the operational state may be performed 
after one or both sides have signaled that the encoding format currently in use will 
be or has been changed. In the case the of Incompatible protocol versions it may be 
decided to abort the bypassing protocol, and to remain in tandem operation, prior to 
entering the contact state or in the contact state, i.e. at a rather early stage of the 
call. 

The infonmation about the encoding format may relate to various aspects depending 
on the specific communication scenario. It may for example Include a codec type that 
is used on a specific side to encode speech signals into an encoded data representa- 
tion. However, the invention is not restricted to the transcoding of speech signals but 
may be applied to handle the transcoding of encoded signals regardless of their 
particular content. 

The information on the encoding capabilities of one side may be used on the other 
side to look up a subset of a list of encoding formats that is supported on the distant 
side. The list of supported encoding format may for example include a supported 
codec list (SCL). The subset or encoding formats supported on the distant side may 
then be compared with the encoding fomiats supported on the local side. On the 
basis of this comparison a change of the encoding format may be effected to Initiate 
bypassing of the transcoding operations using the best encoding format In common. 

The local and distant encoding information including the Information about the 
encoding format currently in use and about encoding capabilities may be signaled 
between the local side and the distant side in various ways. For example the encod- 
ing information may be included in dedicated messages. As another example, the 
encoding information may be included in a message requesting the initiation of a 
bypassing protocol or in a message acknowledging such a request. 

In the case the encoding Information Is Included In messages that are used for 
additional signaling purposes, the Information about encoding capabilities may be 
appended In the fotrn of one or more individual Information blocks to the message. 
For example a first appended block may include the version of a bypassing protocol 
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and an indicator that indicates if the first appended blocl< Is followed by one or more 
further appended blocks that may include a list of one or more encoding fomiats 
supported by the respective side. 

As has already been mentioned, the method set forth above can be performed in 
rontext with setUng up of a TFO between two communication terminals. The inven- 
tion may also be practiced in similar scenarios that involve a series of two or more 
transcoding operations. 

If at least one of the communication terminals uses at least one codec type to 
encode speech signals into an encoded representation, messages may be sent 
between the two trgnscoders to determine if the communication terminals have at 
least one codec type in common. Should this be the case a data connection may be 
established between the two communication terminals without having the need to 
insert transcoding functions into a signal path between the two communication 
terminals. The messages exchanged between the transcoders may include a first 
message that contains information about the encoding format currently used by a 
particular communication terminal and further information about the encoding 
capabilities of the particular communication terminal or transcoder. After the first 
messages have been exchanged, second messages may be exchanged between the 
transcoders as a response to the first messages. The second messages may be 
exchanged if both reported codec types match or regardless of such a match. 

According to a further aspect, the Invention relates to a method of Initiating a TFO in 
a communication network for a speech communication between a first communica- 
tion terminal and a second communication terminal, wherein at least one of the 
terminals uses at least one codec type to encode speech signals into an encoded 
data representation and wherein the communication network includes a first 
transcoder and a second transcoder. Messages are sent from the first transcoder to 
the second transcoder and vice versa to determine if both communication terminals 
have at least one codec type in common and, if this is the case, to establish a data 
connection between the first communication terminal and the second communication 
terminal without having the need to insert transcoding functions into a signal path 
between the first and the second communication terminal. The method comprises 
the step of exchanging messages between the transcoders that contain information 
on the encoder type currently used by the communication terminals and further 
Information on encoding capabilities of the respective communication terminal, and 
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the further step exchanging a further message between the transcoders as a re- 
sponse to the first messages e.g. if both reported codec types match or regardless of 
such a match. 

The Information on encoding capabilities may Include a TFO version number that is 
used by the receiving transcoder to look up a subset of an active codec set that is In 
a mandatory manner supported in the specific TFO version. TTie transcoder may 
compare this subset with the codec types supported by the associated communica- 
tion terminal and the best codec type in common may be chosen to enter into TFO. 

The present invention may be implemented as software, as a hardware solution, or 
as a combination thereof. Thus, the invention also relates to a computer program 
product with program code portions for performing the individual steps of the 
invention when the computer program product is run on one or more computing 
units of the communication network. One or more of the computing units may be 
part of or co-located with a transcoder. TTie computer program product may be 
stored on g computer-readable recording medium. 

As regards a hardware solution, the invention relates to a device for processing 
signals in context with the initiation of the bypassing of a pair of transcoding opera- 
tions performed in series by a first transcoder arranged together with a first commu- 
nication temiinal on a local side of a communication network and by a second 
transcoder arranged together with a second communication terminal on a distant 
side of the communication network. The device comprises a component for receiving 
Information about an encoding format currently in use on the distant side and about 
encoding capabilities of the distant side and further includes a component for trans- 
mitting Information about an encoding format currently in use on the local side and 
about encoding capabilities of the local side to enable on one or on both sides a 
change of the encoding format currently in use prior to initiating the bypassing of the 
transcoding operations. Additionajly, the device may comprise a component for 
generation the information about the encoding format currently in use on the local 
side and about the encoding capabilities of the local side 

The device may be included in a transcoder or in any other unit of the communica- 
tion network. If the device Is included in a transcoder, the transcoder may further 
comprise a component for evaluating local and distant encoding Information and for 
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controlling the change of the encoding format. Thus, the bypassing protocol may 
completely or partially be handled by the transcoder. 

The invention further relates to a communication system including the transcoder 
described above and a separate controller for evaluating local and distant encoding 
information and for controlling the change of the encoding format. For example, the 
controller may be part of a base transceiver station (BTS) or a base station controller 
(BSC). 

Brief Description of the Drawings 

A more complete understanding of the method and device of the present Invention 
may be obtained by reference to the following detailed description when taken in 
conjunction with the accompanying drawings, wherein: 

Fig. 1 is a schemetical diagram of the functional entities handling TFO; 

Fig. 2 illustrates an exemplary TFO configuration between a GSM network and 
a 3G network; 

Fig. 3 is a schematical diagram of the shortest possible TFO_ REQ message; 

Fig. 4 is a schematical diagram of the shortest possible TFO_ REQ_L message; 

Fig. 5 is a schematical diagram of a TFO.REQ message including detailed 
encoding Information; 

Fig. 6a is a table illustrating the content of a TFO version extension block; 

Fig. 6b is a table illustrating the content of a codec attribute head extension 
block; 

Fig. 7 is a schematical diagram of a TFO protocol state machine with the most 
important transittons; 

Rg. 8 is an exemplary flow chart depicting the process of immediate codec 
type optimization according to the invention; 
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Rg. 9 is a flow chart depicting TFO establishment after the Immediate codec 
type optimization of Rg. 8; and 

Rg. 10 IS a table illustrating an exemplary TFO version handling mechanism. 
Description of tiie Preferred Embodiment 

In the following description, for purposes of explanation and not limitation, specific 
details are set forth, such as particular embodiments, signal formats, etc. in order to 
provide a thorough understanding of the present Invention. It will be apparent to one 
skilled In the art that the present Invention may be practiced In other embodiments 
that depart from these^peclflc details. In particular, while the following embodiment 
Is described herein below In context with an exemplary TFO configuration between a 
GSM network and a 3G network, the present invention is not limited to such an 
implementation. It can be utilized in any transcoding environment that allows to 
bypass two or more transcoding operations that are performed in series. Moreover, 
those skilled in the art will appreciate that the functions explained herein below may 
be implemented using individual hardware circuitry, using software functioning in 
conjunction with a programmed microprocessor or general purpose computer, using 
an application specific integrated circuit (ASIC), and/or using one or more digital 
signal processors (DSPs). 

In the following, the Invention will be described in context with the technical specifi- 
cation 3G TS 28.062 V.5.0.0 that has already been mentioned above. The technical 
content of this specification as regards TFO is herewith incorporated by reference. 

Fig. 1 gives a schematical overview over the functional entities of a communication 
system that are involved when TFO is to be established. The communication system 
is shown in simplified form and is illustrative of a call routing mechanism bebween 
two wireless subscriber units terminal A and terminal B. The subscriber units de- 
picted In Fig. 1 may be mobile terminals or fixed site temiinals. In the example 
depleted In Rg. 1 the terminals A and B are exchanging speech signals. Each terminal 
A and B is attached via a respective access network A and B to a transcoder A and B, 
tespectively. The two transcoders A and B communicate via a digital network that 
Includes additional In path equipment (IPE). 
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Each of the two terminals A and B and each of the two transcoders A and B com- 
prises a decoder and an encoder. In the configuration shown in Fig. 1, the Individual 
speech encoder/decoder pairs (speech codecs) are in tandem operation. However, 
the transcoders A and B are each equipped with a control logic (TFO_ Protocol) that 
allows to enter a TFO mode. In such an operational mode the individual transcoders 
A and B are still present in the signal path between the terminals A and B, but their 
respective transcoding functions are bypassed. As becomes apparent from Fig. 1, the 
TFO protocol is fully handled and terminated in the transcoders A and B. 

Before TFO is activated, the transcoders A and B exchange conventional PCM speech 
samples at 64 kbit/s that are transmitted via the digital network. Once TFO Is acti- 
vated, tiie transcoders A and B exchange TFO frames carrying compressed speech 
and in-band signaling. 

In principle, the communication scenario depicted in Fig. 1 applies regardless of the 
specific call configuration, i.e. regardless of the type of access network involved. In 
the following the TFO configuration between a GSM network and a 3G network will 
exemplarily be described in more detail with reference to Fig. 2. The underlying 
principles can, however, readily be applied to TFO configurations involving the same 
or two different GSM networks or TFO configurations involving the same or two 
different 3G networks. 

The communication scenario depicted in Fig. 2 Includes on the GSM side a mobile 
station (MS), a base ti-ansceiver station (BTS), a base station controller (BSC), a 
transcoder and rate adaptor unit (TRAU) and a mobile switching center (MSC). On 
the 3G side a user equipment (UE), a node B, a radio network control (RNC) and a 
media gateway (MGW) with a transcoder (TC) and an MSC server are arranged. The 
GSM network and the 3G network communicate via a digital network including IPE. 

Each of the TRAU and the TC comprise an interface for receiving information about 
an encoding format (codec type) currentiy in use on the respective distant side and 
about encoding capabilities (TFO protocol version and/or a list of selected alterna- 
tively supported codec types) of the respective distant side and for generating and 
h-ansmitting Information about an encoding format cun-ently in use on the respective 
local side and about encoding capabilities of the respective local side. A software 
routine running on an internal processor of each of the TRAU and the TC allows the 



wo 03/092312 



PCT/EP03/04268 



- 12- 

evaluation of the local and distant encoding infonnation and a control of the locally 
used encoding format. 

As has been mentioned before, the TFO protocol is fully handled on the GSM side by 
the TRAU and on the 3G side by the TC. In the following it is assumed that the GSM 
network is arranged on the local side and the 3G network on the distant side. 

As soon as the local TRAU receives and sends PCM speech samples, It initiates the 
TFO negotiation and pre-synchronizes IPEs. The IPEs will then let TFO messages 
pass transparently. The distant TC may initiate the same procedure at the same time. 

At the beginning of the TFO negotiation the local TRAU sends a so-called TFO_REQ 
message, indicating its system identification (GSM) and the speech codec type 
currently used between the MS and the TRAU. If the distant TC supports TFO, It will 
answer by a so-called TFO.ACK message. The distant TC may send TK)_REQ 
messages to the local TRAU and receive an TFO_ACK message from the local TRAU 
at the same time. Should the distant TC not answer with a TFO_ACK message, e.g. 
because the distant TC does not support TFO or because TFO is disabled there, the 
local TRAU aborts the TFO protocol after having sent several TFO_REQ messages 
and returns to its normal mode. It continues, however, to monitor if there are any 
TFO messages inserted in the PCM samples received from the distant TC. 

As has become apparent from the above, the TFO.REQ message identifies the 
source of the message as a TFO capable device. TFO_REQ, as seen from the sender, 
contains the following parameters: 

the system identification of the sender, 

the specific local signature of the sender, 

the codec type locally used at the sender side, 

possibly additional attributes for the codec type locally used at the sender 

side, 

possibly additionally the TFO protocol version supported at the sender side, 
possibly additionally alternative codec types (e.g. a short forni of the Co- 
dec_Ust as defined in TS 28.062 V.5.0.0) , 
possibly additionally, a.future TFO extension. 



wo 03/092312 



PCT/EP03/04268 



-13- 

The TFO_ACK message, which is the response to the TFO.REQ message, contains 
the corresponding parameters as TI=0_REQ for the opposite side. The only exception 
is the local signature that is replaced in the TFO_ACK message by the reflected 
signature as copied from the received TFO_REQ message. 

If during the TFO negotiation on the basis of TFO_REQ and TFO_ACK messages a 
codec mismatch between the local side and the distant side is determined, as well as 
for sporadic updates of information, TFO_REQ_L and TFO_ACK_L messages may be 
exchanged. 

TFO_REQ_L messages contain the following parameters: 

system identification of the sender, 
the specific local signature of the sender, 
the codec type locally used at the sender side, 
a local codec list of alternative codec types, 

possibly additional attributes for the used and the alternative codec types 
possibly additionally the TFO protocol version, 
possibly additionally a future TFO extension. 

A TFO_ACK_L message is the response to a TFO_REQ_L message. The TFO_ACK_L 
message contains the con-esponding parameters as the TFO_REQ_L message for the 
opposite side, except for the local signature which is replaced by the reflected 
signature as copied from the received TFO_REQ_L message. 

Figs. 3 and 4 show the configuration of the shortest possible TFO_REQ message and 
of the shortest possible TFO_REQ_L message. The shortest TFO_REQ_ message 
takes 140 msec for transmission, whereas the shortest TFO_REQ_L message takes 
180 msec. 

The structure of the TFO messages depicted in Figs. 3 and 4 follows the generic in- 
band signaling (IS) message principle. More specifically, the messages depicted in 
Figs. 3 and 4 include a header block consisting of a 20 bit long sequence that is 
followed by a command block of 10 bits Identif/ing the TFO message as a TFO 
request. The thinj block is In each case a system identification block having a length 
of 20 bits and speclf/ing the type of network fi-om which ttie request originates (3G 
GSM, ....). 
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The fourth block of the TFO_REQ message depicted in Fig. 3 includes the local 
signature (SIG) of the sender, the locally used codec type and an indicator S which 
indicates that no further blocks are following (S = short). The fourth block of the 
shortest possible •n=0_REQ_L message depicted in Rg. 4 is similar to the fourth block 
of the TF=0_REQ message but includes an indicator L (long) which points at a codec 
list that is included in a fifth block. 

In order to enable a Ti=0 negotiation that allows establishment of a TFO (i.e. bypass- 
ing of the transcoding operations that are performed by the local TF^AU and the 
distant TC in Fig. 2) on the basis of an optimal codec configuration on both sides, 
one or more additional blocks including encoding infonmation may be appended to 
the shortest possible TFO_REQ message depicted in Rg. 3. Such an extended 
TFO_REQ message is shown In Rg. 5. 

The extended TFO_REQ message of Rg. 5 includes a fifth block called TFO version 
extension block that contains information about the encoding capabilities of the 
respective transcoder and additionally a selector. The information about the encoding 
capabilities relates to the TFO protocol version and subversion (Ver.Sver) supported 
by the respective transcoder. The selector (Sel) indicates if and which additional 
extension blocks are following. The exemplary TFO_REQ message shown in Fig. 5 
includes one additional extension block (sixth block). 

It should be noted that blocks similar to the fifth and sixth block of the TFO_REQ 
message depicted In Rg. 5 may be appended to the TFO_ACK message. |v|oreover, a 
block similar to the fifth block (TFO version extension block) of the TFO_REQ mes- 
sage of Rg. 5 may be appended to the TFO_REQ_L or the TFO_ACK_L message. In 
the following, the additional blocks of the TFO_REQ message of Rg. 5 will exempla- 
rily be described in more detail. 

The TFO version extension block (fifth block in Fig. 5) contains the TFO version (4 
bit) and TFO subversion (4 bit) that are supported by the respective transcoder. The 
supported TFO version and TFO subversion are indicative of the various codec types 
available to a particular transcoder, i.e. indicative of the particular transcoder's 
encoding capabilities. 
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The TFO version extension blocic furtlier includes the selector wliich Is used to 
indicate the number and content of additional extension blocks following the TFO 
version extension block (if any). The selector code "00000" indicates that no further 
extension block is following. If the selector code is set to ''00001" this indicates that a 
particular transcoder supports alternative codec types, which are specified in one or 
more further extension blocks following the TFO version extension block. The selec- 
tor is preferably only used in TFO_REQ or TFO_ACK messages (I.e. not used in 
TFO_REQ_L or TFO_ACK L messages) to provide information on alternative codec 
types at an early stage of TFO protocol, i.e. before TFO is established. 

For each alternative codec type that is offered during TFO negotiation, one codec 
attribute head extension block can be included In theTFO_REQ message. If the 
specified codec type requires additional attributes, then the required number of 
codec atb-ibute extension blocks follow after the codec attribute head extension 
block. The one or more extension blocks following the TFO version extension block 
thus Include information about the encoding capabilities on a particular network side 
in the form of a list of one or more (alternatively) supported codec types. A list of 
alternative codec types is terminated when the two EX bits at the end of a particular 
extension block indicate no further extension blocks f 00") and the next TFO mes- 
sage header is following. 

The exemplary content of the TFO version extension block Is depicted in the table of 
Fig. 6a and the exemplary content of the codec attribute head extension block, which 
Identifies the codec type and the number of additional extension blocks that will 
follow, can be gathered from the table of Rg. 6b. The codec attribute head extension 
block may proceed the codec attribute extension blocks of a codec type if this codec 
type needs additional atb-ibutes. 

The TFO version extension block and any additional extension blocks indicated by the 
"selector may be the last extension blocks of a TFO_REQ, a TFO_REQ_L , a TFO_ACK 
or a TFO_ACK_L message. This is advantageous in order to provide compatibility with 
older protocol versions, which should be able to skip these extension blocks without 
being effected negatively. Thus, a high degree of compatibility between different 
protocol versions can be achieved. Usually, only messages generated on the basis of 
protocol versions higher than a particular version will (and actually should) include 
TFO version extension blocks. If no TFO version extension blocks are detected in a 
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TFO_REQ or similar message, a protocol version lower than a specific version can be 
assumed by the receiving side. 

In the following, an exemplary immediate codec type optimization scenario during 
establishment of a Tl=0 mode for the network configuration depicted in Rg. 2 will be 
described with reference to Figs. 7 to 9. The term "immediate optimization" relates to 
the fact that it will be decided about a change of the codec types currently in use not 
only in the case of non-compatible codec types (codec mismatch), but also if com- 
patible encoding formats are currently used on both sides. Thus, the immediate 
decision can advantageously be performed at a very early stage of the call set-up 
without the nefisssity of a prior evaluation of the question whether or not the cur- 
rently used coClec types are actually compatible. 

Fig. 7 shows a schematic diagram of a state machine, consisting of 17 states that 
describe the TFO protocol process. The five main states are initialization, establish- 
ment, contact, preparation and operation. These states will now be described in more 
detail for the exemplary protocol flow depicted in Figs. 8 and 9. 

Here it is assumed that both sides start with narrowband AMR (AMR-NB), but indi- 
cate that wideband AMR (AMR-WB) is supported also. Usually, such a situation will 
lead to an Immediate TFO setup on the basis of AMR-NB. In the present immediate 
codec type optimization scenario, however, no immediate TFO setup in AMR-NB is 
performed because both sides can use better codec types and configurations. 

The initial state of the TFO protocol is the Not _Active state (see Rgs. 7 and 8). In 
this state the TFO protocol is not active and the TRAU/TC woric in a conventional 
way. The Not_Active state is left and a transition to a Wakeup state is performed 
when a new speech call Is set up and/or when TFO gets enabled. In the Wakeup 
state the TFO protocol waits until PCM speech samples are received. Then a transi- 
tion to the RrstJTry state is performed and TFO_REQ messages similar to those 
depicted in Fig.. 5 are exchanged between the local TRAU and the distant TC for a 
certain period of time. 

As becomes apparent from Fig. 8, each TFO_REQ message includes an Indication 
that the sending side cun^ntly operates on AMR-NB codecs (AMR, NB-ACS). ACS 
stands for active codec set, which in the case of AMR further specifies this encoding 
format. Each TFO_REQ message additionally includes encoding information about the 
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encoding capabilities of sending side (Ver, AI^R-WB). This encoding information 
comprises the version Ver of the supported TFO protocol as well as an indication of 
an alternatively supported encoding format (here: AI^R-WB). 

After the TFO_REQ messages have been exchanged both the TRAU and the TC can 
utilize the obtained information on the encoding capabilities of the respective distant 
side locally to look up a subset of an ACS that is supported on the respective distant 
side. This subset is compared with the codec types supported on the respective local 
side so that the best codec type in common can be chosen for initiating Tl=0. 

As soon as the TRAU and the TC have received and evaluated the TFO_REQ message 
from the opposite side a Contact state can be entered because in the present case 
the codecs match and the ACSs are compatible. In cases where the codecs do not 
match and/or the ACS are not compatible a Mismatch state (if supported) is entered. 
During a codec mismatch resolution routine the TRAU and TC will then exchange 
their full codec capabilities (supported codec list, witii the full range of parameters 
for these codecs) by sending TFO_REQ_L messages or so-called Con_Req frames. 
These are aclcnowledged by TFO_ACK_L messages or so-called Con_Ack frames, 
respectively. 

In the Contact state TFO_ACK messages need to be sent to check the transparency 
of the link to the opposite side. After the exchange of TFO_REQ and/or TFO_ACK 
messages it will be obvious that a prefen-ed TFO configuration (AMR-WB) is possible 
if the codec type at ttie local and at tiie distant side are changed. In this situation the 
TFO protocol stays in the Contact state and performs an immediate codec type 
optimization, i.e. initiates a change of the encoding formats currentiy used by the 
local and tiie distant side. 

In general, an immediate codec type optimization routine is initiated each time both 
sides indicate a specific TFO version (e.g. both sides Indicate a TFO version greater 
than or equal to 5.3, see Fig. 10) and, at the same time, the available information on 
alternative codec types indicates that a change of tiie local and/or distant codec type 
results in a TFO configuration with a higher preference level. Whenever new informa- 
tion about alternative codec types becomes available, the conditions for immediate 
codec type optimization set fortii above are re-evaluated. A possible TFO dedsion 
scheme for codec type optimization is described in 3GPP TS 28.062 V.5.0.0, herewitti 
incorporated by reference. Although this decision scheme relates to codec type 
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optimization at a later stage of the TFO protocol, it can also be applied in mecha- 
nisms for immediate codec type optimization. 

In the present case the TFO decision mechanism will indicate that in the scenario 
depicted in Rg. 8 a change of the codec type to AMR-WB on both sides is preferable. 
I.e. will result in an optimal TFO configuration. Both the local TRAD and the distant 
TC report tiie optimal AMR-WB configuration to initiate a change to AI^R-WB on tfie 
respective air interfaces. As soon as each side has switched to AMR-WB, the opposite 
side is notified thereof with an appropriate TFO_ACK message reporting the currently 
used encoding format (AMR-WB) and (again) the respective TFO protocol version. 

As soon as the TFO_ACK indicating that the encoding format of the opposite side has 
been changed to AMR-WB has been received, the TRAU and the TC know that the 
optimal TFO configuration has been achieved and immediate codec type optimization 
Is complete. Since an AMR-WB codec type has been selected, the TRAU and the TC 
send rate control commands downlink to tiieir BTS/RNC In order to steer the uplink 
codec mode down to the TFO setup mode for a save TFO setup. Additionally, a 
further TFO_ACK message is sent to the opposite side and the TFO protocol transits 
into the Wait_RC state as depicted in Figs. 7 and 8, This Wait_RC state exists only 
when the locally used codec type is an AMR or AMR-WB codec. For all other codec 
types this state is not entered and all transitions go directly into the Konnect state, 
thus skipping the Wait_RC state (see Fig. 7). 

In the Wait_RC state the TFO protocol waits for the acknowledgment from the 
BTS/RNC that the rate control command has been received and executed. Then the 
TC sends a so-called TFOJTRANS message to bypass the IPEs, starts sending TFO 
frames and the TFO protorol transits into a Konnect state. 

In the Konnect state the TFO frames and possibly embedded TFO messages are sent 
as long as correct TFO messages are received. The first received TFO frame causes 
tiie ti^ansition from the Konnect state into tiie Operation state. 

In the operation state, tiie main state of the TFO protocol, TFO frames are sent and 
received. Thus, the TFO connection Is fully operating. As becomes apparent from Fig. 
9, a furttier codec type optimization commands Con_Req and Con_Ack may be sent 
in the operation state when TFO is established. 
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As has been explained above, the objective of Immediate codec type optimization is 
to switch the codec type on the local and/or the distant side (if tills results in a 
preferred TRD configuration) while the IK) protocol is in the Contact state, i.e. at a 
very early state of the TFO protocol. The required Information to decide if immediate 
codec type optimisation shall be performed is comprised in tiie TFO_REQ and 
TFO_ACK messages including the TFO version extension blocl< and (optionally or 
mandator/) additional extension blocks specifying selected alternatively supported 
encoding formats. If a preferred TFO configuration becomes possible by changing 
the local and/or distant codec type, both sides remain in the Contact state as long as 
immediate codec type optimization is performed, I.e. until the local and/or the distant 
side has/have changed the codec type. After the switching, TFO protocol continues 
as usual. 

Immediate codec type optimization using information about encoding capabilities in 
the form of TFO protocol versions allows an effective TFO version handling. Prefera- 
bly, immediate codec type optimization becomes effective only in TFO protocol 
version 5 or higher. If either the local or the distant side is using a lower TFO proto- 
col version, no immediate codec type optimization is used. Hence, the protocol is 
compatible with older versions that do not include immediate codec type optimiza- 
tion. A switch to a different codec type will nonetheless be possible using the ordi- 
nary codec type optimization routines that have been defined for tiie Mismatch or 
Operation state described above. 

The exchange of the TFO protocol version has further advantages. For example, the 
usage of spedfic features and/or encoding formats may be associated to specific 
versions of the TFO protocol. Hence, when receiving a TFO_REQ/TFO_ACK message 
with a specific version number, the receiving side knows which features and/or 
encoding formats may be used. 

In the present scenario the smallest defined TFO protocol version number is 0.0. It 
stands for all TFO protocol versions before 5.3. All numbers betiween 0.0 and 5.3 
may be reserved for future use. If the local and the distant version number differ, 
the smaller version number shall have precedence and shall be applied on both sides. 
The table of Fig. 10 gives an overview over an exemplary TFO version handling 
mechanism. 
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For example, the knowledge of the protocol version number may be used to decide 
on the encoding fomiat to transport the so called "TFO configuration parameters". 
After a successful TFO negotiation, when the protocol is in the Operation state, either 
old or new (so called "generic") configuration frames can be used because both sides 
Icnow the TFO version of the opposite side and can flecibly decide how to handle any 
subsequent changes of the encoding format. A possible scenario for the handling of 
configuration frames is depicted in the right hand column of the table that is shown 
in Fig. 10. 

For example, the following constellations can be handled: 

a) V4.X <-> V4.x: use old Configuration frames or 

^ the TFO_REQ_L and TFO_ACK_L protocol. 

b) V4.X <-> V5.x: use old Configuration frames or 

the TFO_REQ_L and TFO_ACK_L protocol. 

c) V5.X <-> V5.x: use new Configuration frames or 

the TFO.RECLL and TFO_ACK_L protocol. 

Furthermore, the exchange of the protocol version number also allows more sophisti- 
cated decisions in the TFO decision block of Fig. 8. For example, a decision "No TFO 
at all" may result from the fact that the TFO version numbers or other configuration 
parameters reveal that the current call scenario is not fevorable for TFO. In TFO 
protocol version 4.x.y TFO configuration parameters are exchanged as so called "old 
configuration ft-ames" In a very specific and somehow scattered form within the 
speech and no-speech frames. Accordingly, the implementation needs some elTort. 
With the early exchange of the TFO protocol version number it is now possible that a 
version 5 transcoder rejects the TFO attempt of a version 4 transcoder and thus has 
a potential for cost saving. 

As has become apparent from the above, the exchange of information about the 
encoding capabilities leads to a faster TFO setup as regards an optimal encoding 
format like AMR-WB. Furthermore, the extension blocks used for signaling the 
encoding capabilities guarantee that the TFO messages are better prepared for 
further extensions. The TFO version negotiation described above allows to flexibly 
decide in an early stage of the TFO protocol whether TFO setup is desirable or not. 
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Although embodiments of the method and device of the present invention have been 
illustrated in the accompanying drawings and described in the foregoing detailed 
description. It will be understood that the invention Is not limited to the embodiments 
disclosed, but is capable of numerous rearrangements, modifications and substitu- 
tions without departing from the spirit of the invention as set forth and defined by 
the following claims. 



